Systems and methods for error tracking and recovery in an expectation-based memory agent checker

ABSTRACT

Systems, methods and software products are provided for error tracking and recovery in an expectation-based memory agent checker. An electronic device design is simulated with stimuli of one or more test cases, to generate simulated output transaction events. The simulated output transaction events are compared with expected output transaction events. Remaining expected output transaction events for a transaction are identified based upon mismatch between (a) at least one of the simulated output transaction events of the transaction and (b) the expected output transaction events of the transaction.

RELATED APPLICATIONS

This application is related to the following commonly owned and co-filedU.S. patent application, filed Feb. 3, 2004 and incorporated herein byreference: Transaction logging and intelligent error reporting in anexpectation-based memory agent checker (Attorney Docket 200208665-1).

BACKGROUND

Semiconductor technology has advanced at a high rate over the pastseveral decades, resulting in electronic devices with enormouscomplexity, such as very large scale integration (VLSI) processors. Eachsuch electronic device typically consists of a large number of diversesubsystems; the interaction between these subsystems is also verycomplex. The likelihood of design errors within the electronic deviceincreases with increased interaction between the subsystems.Accordingly, the cost of converting an electronic device design into aphysical device still remains very high since a design error present inthe physical device is very costly to correct.

Elimination of design errors as early as possible in a design cycle ofthe electronic device helps minimize the overall design period and alsoreduces associated development costs. Interaction between subsystems ofthe electronic device design is thus extensively tested prior tocommitting the electronic device design to physical form. In one exampleof this testing, subsystems of the electronic device design arerepeatedly simulated to test the interaction between the subsystems, andbetween the subsystems and external devices, to identify design errors.

Though it is desirable to test as many of these interactions aspossible, the amount of testing is limited by time and cost. Therefore,any increase in the efficiency of testing, and/or in the computer aideddesign (CAD) tools that facilitate this testing, results in improveddevice reliability and/or reduced development time and cost.

In addition, the latest generation of processors include a particularlydiverse range of subsystems that require improved design and developmenttechniques. For example, modern high performance multi-core processors(such as the Hewlett Packard/Intel “Montecito” processor) representultra-complex integrated circuit design and, as such, challenge CADtools and development techniques. Extensive testing is thus required,particularly prior to reducing the multi-core processor design tophysical form.

Within the multi-core processor, memory agents handle memory operationsor transactions that access memory (e.g., shared memory and caches). Forexample, a processor core may read a line of memory stored in one ormore locations within the multi-core processor, such as in the sharedmemory and caches. The memory agents cooperate to determine the sourcefrom which the line of memory should be read for the multi-coreprocessor.

The memory agents, shared memory and caches may connect in a number ofways, such as by a bus or by a point to point link using a suitableprotocol. A single memory transaction may therefore be quite complex,involving transmission of requests and data back and forth among thememory agents, shared memory and caches. The sequence of transmissionsdepends upon the locations and states of the line of memory and the busprotocol employed. Testing the operation of the memory agents is anextremely complex and data-intensive procedure.

A point to point link is a switch-based network that may have one ormore crossbars that act as switches between the memory agents, sharedmemories, the processing cores, and other devices. Transactions on thepoint to point link are packet-based; each packet has a header withrouting and other information. Information within the transactions isthus directed to specific locations within the multi-core processor andare routed appropriately by the crossbars.

FIG. 1 is a flowchart illustrating one prior art process 100 fortesting, modifying and re-testing an electronic device design prior tocommitting the electronic device design to physical form. In step 102,process 100 creates one or more test cases for the electronic devicedesign. Each test case typically employs one or more stimuli, usedduring simulation of the electronic device design, and one or morepredicted outputs (‘expectations’). In one example, step 102 isperformed by a design engineer who creates one or more tests for theelectronic device design. In another example, step 102 is performedautomatically by an Electronic Computer Aided Design (E-CAD) analysistool that processes the electronic device design to produce the testcases.

In step 104, process 100 simulates the electronic device design andperforms the tests of step 102. For example, in step 104, circuitry ofall or part of the electronic device design is entered into an E-CADsimulation tool. The simulation uses the stimuli of each test case (fromstep 102) to produce simulation output.

In step 106, process 100 compares simulation output of step 104 to thepredicted output of step 102, and logs results for each test case. Step106 may, for example, send error messages to an engineering designterminal to indicate detected errors. In one example of step 106,process 100 compares, for each test case, simulation output of step 104to predicted output of step 102, indicating that the test is successfulif the simulation output matches the predicted output. If, in step 106,process 100 determines that an unexpected event occurred duringsimulation step 104, process 100 indicates that incorrect operation ofone or more subsystems of the electronic device design has occurred. Inanother example of step 106, process 100 does not receive a predictedevent of step 102, again indicating incorrect operation of one or moresubsystems of the electronic device design. In another example of step106, process 100 determines that the simulation output does not matchthe predicted output of step 102, again indicating incorrect operationof one or more subsystems of the electronic device design.

Step 108 is a decision. In step 108, if one or more errors are detectedin step 106, process 100 continues with step 110; otherwise process 100terminates, indicating that testing of the electronic device design iscomplete and that the electronic device design operates correctly. If noerrors are detected in step 108, for example, process 100 terminates andindicates that the electronic device design is ready for manufacture. Instep 110, process 100 modifies the electronic device design to correcterrors detected in step 106, or, in certain cases, modifies the expectedoutput, determined in step 102, to change error definitions.

Steps 104, 106, 108 and 110 are typically repeated many times, eachiteration correcting problems identified in the electronic device designand/or test cases. When no errors are detected in step 106, theelectronic device design is considered to operate correctly for all testcases created in step 102. If no further testing of the electronicdevice design is required, process 100 terminates and the electronicdevice design is committed to physical form.

Once the device is manufactured, it is again tested for correctoperation and, if successful, the electronic device is often massproduced. If further errors are detected, the electronic device designmay again be modified 110 in process 100 and then re-tested withadditional test cases.

During operation of process 100, one design error typically causes manytest errors, often resulting in duplicate and bogus error indications.Where the test case simulates interaction between one or moresubsystems, a design error within one subsystem may therefore result ina plurality of cascaded error messages from process 100. These cascadederror messages (including repeated error messages) may obscure realerrors in the system. A verification engineer is therefore required tocarefully search through all reported errors to identify the realerrors. This searching is difficult and time consuming, resulting inadditional development time and cost.

Design modification step 110 of process 100 may thus require extensiveanalysis of transaction and error logs to identify real errors in theelectronic device design. This transaction and error log analysis isoften very labor intensive and can occur many times during thedevelopment of the electronic device design. The large number oftransaction and error log messages created during simulation of theelectronic device design makes it difficult for the verificationengineer to identify fundamental causes of error, resulting indevelopment delays and increased development costs. In one example, theverification engineer manually traces back through many hundreds oftransaction and error log messages to determine fundamental causes oferror in memory agent transactions. Further, the error messages andlogging information typically produced by process 100 are bothvoluminous and cryptic, requiring skilled interpretation.

SUMMARY OF THE INVENTION

In one embodiment, a method is provided for error tracking and recoveryin an expectation-based memory agent checker. An electronic devicedesign is simulated with stimuli of one or more test cases, to generatesimulated output transaction events. The simulated output transactionevents are compared with expected output transaction events. Remainingexpected output transaction events for a transaction are identifiedbased upon mismatch between (a) at least one of the simulated outputtransaction events of the transaction and (b) the expected outputtransaction events of the transaction.

In another embodiment, a method is provided for error tracking andrecovery in an expectation-based memory agent checker. An electronicdevice design is simulated with stimuli of one or more test cases tosimulate a transaction. The simulated events of the transaction areobserved. The simulated events are sequentially compared with expectedtransaction events of the transaction. If a mismatch occurs: one errormessage for the mismatch is generated; remaining expected events for thetransaction are identified; if possible, unmatched simulated events arematched to the identified remaining expected events; if possible,simulated events for a next transaction are matched to expected eventsfor the next transaction without comparison to the identified remainingexpected events.

In another embodiment, a system is provided for error tracking andrecovery in an expectation-based memory agent checker. One or more testcases contain stimuli. An expectation generator generates expectedevents based upon observed simulation events. A simulator simulates anelectronic device design and generates simulated output transactionevents. A result checker (a) compares simulated output transactionevents and expected output transaction events, (b) identifies remainingexpected output transaction events for a transaction when a mismatchoccurs between the simulated output transaction events and expectedoutput transaction events for the transaction, and (c) generates anerror message for the mismatch. A transaction and error log stores theerror message.

In another embodiment, a system is provided for error tracking andrecovery in an expectation-based memory agent checker, including: meansfor stimulating an electronic device design with stimuli of one or moretest cases, to generate simulated output transaction events; means forcomparing the simulated output transaction events with expected outputtransaction events; and means for identifying remaining expected outputtransaction events for a transaction based upon mismatch between (a) atleast one of the simulated output transaction events of the transactionand (b) the expected output transaction events of the transaction.

In another embodiment, a software product has instructions, stored oncomputer-readable media, wherein the instructions, when executed by acomputer, perform steps for error tracking and recovery in anexpectation-based memory agent checker, including: instructions forstimulating a simulated electronic device design with stimuli of one ormore test cases, to generate simulated output transaction events;instructions for comparing the simulated output transaction events withexpected output transaction events; and instructions for identifyingremaining expected output transaction events for a transaction basedupon mismatch between (a) at least one of the simulated outputtransaction events of the transaction and (b) the expected outputtransaction events of the transaction.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a flowchart illustrating a prior art design process fortesting an electronic device design.

FIG. 2 is a block diagram illustrating one system for error tracking andrecovery in an expectation-based memory agent checker.

FIG. 3 a is a block diagram illustrating exemplary data flow and logiccontrol during simulation and verification of an electronic devicedesign by cooperation of the simulator and the checker of FIG. 2.

FIG. 3 b is a block diagram illustrating exemplary simulated andexpected transaction events.

FIG. 3 b is a block diagram illustrating simulated and expectedtransaction events that include an error.

FIG. 4 a is a flowchart illustrating one process for error tracking andrecovery in an expectation-based memory agent checker.

FIG. 4 b is a flowchart illustrating one sub-process of FIG. 4 a.

FIG. 5 is a flowchart illustrating one process for error tracking andrecovery in an expectation-based memory agent checker.

DETAILED DESCRIPTION OF THE FIGURES

FIG. 2 is a block diagram illustrating one system 200 for error trackingand recovery in an expectation-based memory agent checker. System 200has a computer 202 with a computer memory 204, a processor 206, astorage device 208, and a user interface 210. System 200 also includesan interactive device 212 connected to user interface 210 of computer202. Interactive device 212 is, for example, a computer terminal used bya verification engineer to interact with computer 202. Storage device208 is, for example, a disk drive that stores software and data ofcomputer 202.

Storage device 208 is shown with a simulator 220, a checker 222, anelectronic device design 216 and test cases 230. Simulator 220, checker222, electronic device design 216 and test cases 230 are loaded intocomputer memory 204 by processor 206 such that simulator 220 and checker222 are executable by processor 206. Simulator 220, checker 222,electronic device design 216 and test cases 230 are therefore shown indashed outline in computer memory 204 for purposes of illustration.Electronic device design 216 is, for example, a very large scaleintegration (VLSI) circuit design of an electronic device that includesa memory agent 218. Memory agent 218 handles memory operations, ortransactions that access memory (e.g., shared memory and caches), ofelectronic device design 216.

In operation, simulator 220 and checker 222 cooperate to test electronicdevice design 216, using test cases 230 to produce transaction and errorlog 238. In particular, simulator 220 first simulates electronic devicedesign 216 (such as shown in FIG. 3 a), then stimulates the simulatedelectronic device design 216 using test cases 230. Checker 222 thenobserves simulator status 240 to verify correct operation of memoryagent 218, producing transaction and error log 238.

By way of illustrative operation, a verification engineer utilizesinteractive device 212 to instruct simulator 220 and checker 222,through user interface 210, to test electronic device design 216. Testcases 230 include stimuli events 232 that are used by simulator 220 tostimulate electronic device design 216. In one example, stimuli events232 are processor instructions for simulated execution by processingcores of electronic device design 216 to stimulate memory agent 218.Checker 222 includes an expectation generator 224 that generatesexpectations 236, stored in computer memory 204, as shown. Expectations236 define expected output events of memory agent 218 during simulationof electronic device design 216 using stimuli events 232. Optionally,test cases 230 may include user expectations 234 that are created by oneor more verification engineers, to define expected output of memoryagent 218 during simulation of electronic device design 216; userexpectations 234 may be loaded into expectations 236.

Checker 222 observes simulator status 240 and utilizes a result checker226, illustratively shown within checker 222, to compare output eventsof memory agent 218 against expectations 236 and generate transactionand error log 238, illustratively shown in storage device 208. Resultchecker 226 may also modify expectations 236 to enable error trackingand recovery, thereby preventing unwanted and duplicate error messagesfrom being written to transaction and error log 238. Transaction anderror log 238 may also be output to other devices external to computer202, for example, to interactive device 212.

FIG. 3 a is a block diagram illustrating exemplary data flow and logiccontrol during simulation of electronic device design 216 by simulator220, FIG. 2, and observation of simulator status 240′ by checker 222,FIG. 2. FIG. 3 b is a block diagram illustrating exemplary simulatedtransaction events of simulated transaction 304 and exemplary expectedtransaction events of memory read expectations 308 that result frommemory read request 302. FIGS. 3 a and 3 b are best viewed together withthe following description.

In FIG. 3 a, simulator 220 is illustratively shown with a simulatedelectronic device design 216′ and simulator status 240′. Simulatedelectronic device design 216′ includes simulated memory agents 218′,314, 315, 316, a simulated cache memory 306 and a simulated processingcore 313. Simulated memory agents 218′, 314, 315, 316 communicatethrough a simulated point to point link 318; simulated memory agent 218′communicates with simulated cache memory 306 via a simulatedcommunication link 319; and simulated processing core 313 communicateswith simulated memory agent 314 via a simulated communication link 317.Simulated memory agent 314 is, for example, a memory agent of simulatedprocessing core 313. Simulated memory agents 315 and 316 are, forexample, memory agents of other processing cores (not shown) withinsimulated electronic device design 216′. In this example, simulatedmemory agent 218′ is tested by checker 222′.

A memory read request 302, of stimuli events 232, is used to stimulatesimulated electronic device design 216′. In one example, memory readrequest 302 is a processor instruction that, when executed by simulatedprocessing core 313, causes simulated processing core 313 to read a lineof memory within simulated cache memory 306, initiating a simulatedtransaction 304 between simulated memory agent 218′ and simulated cachememory 306 via communication link 319. FIG. 3 b illustrates events ofsimulated transaction 304. In particular, simulated processing core 313causes simulated memory agent 314 to generate a memory read line event320 that is sent from simulated memory agent 314 to simulated memoryagent 218′, via point to point link 318, thus initiating simulatedtransaction 304.

In testing simulated memory agent 218′, checker 222′ observes simulatorstatus 240′ to identify events associated with simulated memory agent218′. In particular, checker 222′ observes memory read line event 320and utilizes expectation generator 224′ to generate expected events 322within memory read expectations 308. In the example, expectationgenerator 224′ has knowledge of simulated processing core 313 andsimulated memory agents 218′, 314, 315 and 316. Expectation generator224′ therefore generates four expected events within expected events322: a read message event 324 that simulated memory agent 218′ expectsto send to simulated cache memory 306; a snoop event 326 that simulatedmemory agent 218′ expects to send to simulated memory agent 315; a snoopevent 328 that simulated memory agent 218′ expects to send to simulatedmemory agent 316; and a transaction complete event 334 that simulatedmemory agent 218′ expects to send to simulated memory agent 314.

Snoop events 326 and 328 are generated by simulated memory agent 218′ torequest the line of memory from simulated memory agents 315, 316, sincethe line of memory may be modified and stored in other memories (notshown) associated with simulated memory agents 315, 316. Note that, inthe example, expectation generator 224′ does not predict responses tosnoop events 326 and 328. However, expectation generator 224′ mayoperate to predict responses to snoop events 326 and 328 and/or userexpectations 234 may define expected events of simulated transaction 304and are input to expectations 236.

Continuing with the example, checker 222′ next observes read line event336, generated by simulated memory agent 218′, within simulatedtransaction 304 and utilizes result checker 226 to match read line event336 to read line event 324 within memory read expectations 308. Oncematched, expected events are removed from memory read expectations 308.Checker 222′ next observes snoop events 338, 340, which result checker226 matches to snoop events 326, 328, respectively. Checker 222′ thenobserves read line event 342, sent by simulated cache memory 306 andcontaining the contents of the requested line of memory. Upon receivingread line event 342, simulated memory agent 218′ stores the contents ofthe line of memory internally, and waits for responses to snoop events326, 328 to learn if the value of the line of memory is current. Checker222′ next observes snoop invalid event 344, sent by simulated memoryagent 315 to indicate that the line of memory, requested by snoop event338, is not stored in memory associated with simulated memory agent 315.Since expectation generator 224′ does not generate expectations forsnoop events 338, 340, in this example, snoop invalid event 344 is notmatched to events of memory read expectations 308.

Checker 222′ next observes read line event 346, sent by simulated memoryagent 316 and containing a modified value for the line of memory. In oneexample of operation, in response to snoop event 338, simulated memoryagent 316 retrieves a modified value of the line of memory from memorycache associated with simulated memory agent 316. Checker 222′recognizes read line event 346 as an input to simulated memory agent218′ and therefore utilizes expectation generator 224′ to generateexpected events 348 resulting from read line event 346. Since simulatedmemory agent 316 responded with a modified value for the line of memory,expectation generator 224′ generates (a) a send line event 350, sincesimulated memory agent 218′ is expected to send the modified value ofthe line of memory to simulated cache memory 306 (to update the value ofthe line of memory within simulated memory cache 306), and (b) a sendline event 352, since simulated memory agent 218′ is expected to sendthe modified value of the line of memory to simulated memory agent 314.

Checker 222′ next observes send line event 354, sent by simulated memoryagent 218′ to simulated cache memory 306 and containing the modifiedvalue of the line of memory; and result checker 226 matches send lineevent 354 to send line event 350. Checker 222′ next observes send lineevent 356, sent by simulated memory agent 218′ to simulated memory agent314. Send line event 356 contains the modified value of the line ofmemory received from simulated memory agent 316 in read line event 346.Result checker 226 matches send line event 356 to send line event 352 ofexpectations 236. Checker 222′ next observes transaction complete event358, sent by simulated memory agent to 218′ simulated memory agent 314,to terminate simulated transaction 304. Result checker 226 matchestransaction complete event 358 to transaction complete event 334, andthus determines that simulated transaction 304 successfully completes.In this example, memory agent 218′ attaches the modified value of theline of memory to the transaction complete event 334. Result checker 226may write an appropriate message (e.g., message 312) to transaction anderror log 238 indicating the success of simulated transaction 304.

Using the example of FIGS. 3 a and 3 b, FIG. 3 b illustrates oneexemplary scenario of an error event 378 occurring in place of expectedsnoop event 328, FIG. 3 b. In the example of FIG. 3 c, checker 222′observes memory read line event 320 and uses expectation generator 224′to generate expected events 322. Simulated transaction 304 and events336 and 338 are observed and matched, respectively, by checker 222′ andresult checker 226.

In the example of FIG. 3 c, checker 222′ then observes error event 378,output from simulated memory agent 218′, and utilizes result checker 226to match error event 378 to remaining expected events 328, 334 withinmemory read expectations 308. In the current example, result checker 226fails to match error event 378 and generates one or more error messages(e.g., messages 312) indicating the erroneous event.

Result checker 226 then modifies remaining events 328, 334 of memoryread expectations 308 to prevent cascading of error messages. In oneexample, result checker 226 sets a status of remaining events 328, 334to ‘zombie’ to indicate that these events are ignored if observed, andfurther that these events do not generate error messages if not observed(i.e., a next event 384 of a next simulated transaction 380 nextobserved by checker 222′). Thus, by modifying the status of eventswithin expectations 236 associated with simulated transaction 304,result checker 226 prevents further error generation for simulatedtransaction 304 while attempting continued synchronization for nextsimulated transaction 380. Remaining events 342, 356, 358 of simulatedtransaction 304 are matched with remaining event 334 of memory readexpectations 308, if occurring, and do not generate further errormessages should they not occur.

In another example of an error transaction, simulated memory agent 218′prematurely sends transaction complete event 358 for simulatedtransaction 304. Checker 222′ observes transaction complete event 358and uses result checker 226 to match transaction complete event 358 totransaction complete event 334 while expecting other events of simulatedtransaction 304. In this example, result checker 226 determines thatsimulated transaction 304 is not yet complete, and sends an errormessage (e.g., messages 312) to transaction and error log 238. Resultchecker 226 then resynchronizes with following transactions and eventsby identifying remaining expected events of memory read expectations 308and sets a status of the identified events to zombie. Result checker 226therefore recognizes events of simulated transaction 304, if occurring,and does not generate further error messages should further events ofsimulated transaction 304 not occur.

It should be apparent that the use of the zombie status withinexpectations 236 allows result checker 226 to maintain synchronizationbetween simulator status 240′ and expectations 236 to prevent alreadydetected errors from being repeated and cascaded. Transaction and errorlog 238 is thereby uncluttered by redundant and incorrect errormessages, allowing the verification engineer to quickly determine realerrors.

FIG. 4 a is a flowchart illustrating one process 400 for error trackingand recovery in an expectation-based memory agent checker. Process 400is, for example, implemented by simulator 220, expectation generator224′ and result checker 226 of FIG. 3 a. In step 402, process 400initializes a simulation of an electronic device design. In one exampleof step 402, simulator 220 simulates electronic device design 216 assimulated electronic design 216′, creating simulated memory agents 218′,314, 315, 316, a simulated cache memory 306 and simulated processingcore 313. In step 404, process 400 observes events within simulatorstatus 240′ resulting from stimulation of simulated electronic devicedesign 216′ by one or more stimuli of stimuli events 232. For example,in step 404, process 400 observes memory read line event 320 ofsimulated transaction 304. Step 406 is a decision. In step 406, if theobserved event of step 404 is an input event of simulated memory agent218′, process 400 continues with step 408; otherwise process 400continues with step 410. In step 408, process 400 generates expectationsfor the observed event of step 404. In one example of step 408,expectation generator 224′ processes memory read line event 320,observed in step 404, and generates memory read expectations 308 thatdefine one or more of expected events of simulated transaction 304. Instep 410, process 400 verifies observed events within simulator status240′ against expected events of expectations 236. In one example of step410, process 400 verifies observed events of simulated transaction 304against memory read expectations 308. In step 410, process 400 verifiesevents of simulator status 240′ against expectations 236, using aprocess 430 of FIG. 4 b. Process 430 may modify expectations 236 andsend messages to transaction and error log 238. In one example of step410, process 430 is implemented by result checker 226.

Steps 404, 406, 408 and 410 of process 400 are repeated one or moretimes as indicated by loop boundaries 403 and 411. For example, steps404, 406, 408 and 410 are repeated for each observed event withinsimulator status 240′.

FIG. 4 b illustrates one process 430 utilized in step 410 of process400. In one embodiment, process 430 processes simulator status 240′ andexpectations 236. Step 432 is a decision. In step 432, process 430determines if the observed event of step 404, process 400, matches thenext expected event within expectations 236. If the observed eventmatches the next expected event, process 430 continues with step 434;otherwise process 430 continues with step 436. In step 434, the matchedexpected event in expectations 236 is cleared. In one example of step434, process 430 marks the matched expected event as complete, makingthe following expected event the next expected event.

Step 436 is a decision. In step 436, process 430 determines if theobserved event matches an event with a zombie status within expectations236. If the observed event matches a zombie event, process 430 returnscontrol to process 400; otherwise process 430 continues with step 438.In step 438, process 430 sends an error message to transaction and errorlog 238, indicating that the observed event is unexpected. In step 439,process 430 modifies the status of expected events associated with thecurrent transaction to zombie.

Step 440 is a decision. If, in step 440, the received event terminatesthe current transaction, process 430 continues with step 442; otherwiseprocess 430 returns control to process 400. Step 442 is a decision. If,in step 442, process 430 determines that the observed event starts a newtransaction, process 430 continues with step 444; otherwise process 430returns control to process 400. In step 444, process 430 clears zombieevents for the current or completed transaction. In one example of step444, result checker 226 marks events associated with the current orcompleted transaction as complete. In another example of step 444,result checker 226 deletes events associated with the current orcompleted transaction.

Step 446 is a decision. If, in step 446, process 430 determines thatexpected events associated with the current or completed transaction arestill expected, process 430 continues with step 448; otherwise process430 returns control to process 400. In step 448, process 430 producesone or more warning messages indicating that expected events were notreceived for the current or completed transaction.

FIG. 5 is a flowchart illustrating one process 500 for error trackingand recovery in an expectation-based memory agent checker. Process 500is, for example, implemented by checker 222, FIG. 2. In step 502, thesimulated electronic device design is stimulated with stimuli of one ormore test cases, to generate simulated output transaction events. Instep 504, the simulated output transaction events are compared withexpected output transaction events. In step 506, remaining expectedoutput transaction events are identified for a transaction based uponmismatch between (a) at least one of the simulated output transactionevents of the transaction and (b) the expected output transaction eventsof the transaction.

Changes may be made in the above methods and systems without departingfrom the scope hereof. It should thus be noted that the matter containedin the above description or shown in the accompanying drawings should beinterpreted as illustrative and not in a limiting sense. The followingclaims are intended to cover all generic and specific features describedherein, as well as all statements of the scope of the present method andsystem, which, as a matter of language, might be said to fall therebetween.

1. A method for error tracking and recovery in an expectation-basedmemory agent checker, comprising: stimulating an electronic devicedesign with stimuli of one or more test cases, to simulate atransaction; observing simulated events of the transaction; comparingthe observed simulated events with expected events; identifyingremaining expected events for the transaction based upon mismatchbetween at least one of the simulated events and the expected events. 2.The method of claim 1, further comprising generating the expected eventsbased upon observed simulated events input to a simulated memory agent.3. The method of claim 2, the step of generating comprisingelectronically processing the observed simulated event input to thesimulated memory agent to determine the expected events.
 4. The methodof claim 2, the step of generating comprising utilizing user input asthe expected events.
 5. The method of claim 1, wherein the step ofidentifying comprises setting a status for the remaining expectedevents.
 6. The method of claim 1, further comprising the step ofgenerating an error message for the transaction based upon the mismatch.7. The method of claim 1, the step of comparing comprising sequentiallycomparing the simulated events, until the mismatch occurs, with theexpected events.
 8. The method of claim 7, the step of comparing furthercomprising attempting synchronization after the mismatch by comparingand matching remaining simulated events with the remaining expectedevents.
 9. The method of claim 1, the step of identifying comprisingsetting a status for each unmatched expected event, the statusindicating that the unmatched expected event does not generate an errormessage.
 10. The method of claim 9, the step of setting a statuscomprising setting the unmatched expected event to zombie.
 11. Themethod of claim 1, further comprising the step of logging error messagesfor mismatches between the simulated events and the expected eventsunless the mismatches correspond to the identified remaining expectedevents.
 12. The method of claim 1, further comprising the step ofsimulating the electronic device design.
 13. A method for error trackingand recovery in an expectation-based memory agent checker, comprising:stimulating an electronic device design with stimuli of one or more testcases to simulate a transaction; observing simulated events of thetransaction; sequentially comparing the simulated events with expectedevents of the transaction; if a mismatch occurs: generating one errormessage for the mismatch; identifying remaining expected events;matching, if possible, unmatched simulated events to the identifiedremaining expected events; matching, if possible, simulated events for anext transaction to expected events for the next transaction withoutcomparison to the identified remaining expected events.
 14. The methodof claim 13, further comprising generating an error message for themismatch.
 15. The method of claim 13, wherein the step of identifyingcomprises setting a status for the remaining expected events.
 16. Asystem for error tracking and recovery in an expectation-based memoryagent checker, comprising: one or more test cases containing stimuli; anexpectation generator for generating expected events based upon observedsimulation events; a simulator for simulating an electronic devicedesign and generating simulated output transaction events; a resultchecker for comparing simulated output transaction events and expectedoutput transaction events, for identifying remaining expected outputtransaction events for a transaction when a mismatch occurs between thesimulated output transaction events and expected output transactionevents for the transaction, and for generating an error message for themismatch; and a transaction and error log for storing the error message.17. The system of claim 16, the transaction and error log storingsimulated transactions.
 18. The system of claim 17, wherein transactionsare stored for matches between the simulated output transaction eventsand the expected output transaction events, and wherein error messagesare stored for unmatched expected output transaction events unless theexpected output transaction event has been identified.
 19. A system forerror tracking and recovery in an expectation-based memory agentchecker, comprising: means for stimulating an electronic device designwith stimuli of one or more test cases, to generate simulated outputtransaction events; means for comparing the simulated output transactionevents with expected output transaction events; and means foridentifying remaining expected output transaction events for atransaction based upon mismatch between (a) at least one of thesimulated output transaction events of the transaction and (b) theexpected output transaction events of the transaction.
 20. The method ofclaim 19, wherein the means for identifying comprises means for settinga status for the remaining expected output transaction events.
 21. Asoftware product comprising instructions, stored on computer-readablemedia, wherein the instructions, when executed by a computer, performsteps for error tracking and recovery in an expectation-based memoryagent checker, comprising: instructions for stimulating a simulatedelectronic device design with stimuli of one or more test cases, togenerate simulated output transaction events; instructions for comparingthe simulated output transaction events with expected output transactionevents; and instructions for identifying remaining expected outputtransaction events for a transaction based upon mismatch between (a) atleast one of the simulated output transaction events of the transactionand (b) the expected output transaction events of the transaction.